home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / networking / 3271 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.networking
  4. Subject: Re: Announce: AWeb 1.0 released!
  5. Date: 30 Mar 1996 22:00:14 +0100
  6. Organization: dis-
  7. Message-ID: <4jk7cu$jcn@serpens.rhein.de>
  8. References: <4jk0hc$g8q@walrus.megabaud.fi>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. petrin@walrus.megabaud.fi (Petri Nordlund) writes:
  12.  
  13. >>That's something that you do not want. You want I/O, decoding and
  14. >>rendering done concurrently and this means: at the same priority so
  15. >>that they are timesliced.
  16.  
  17. >  I don't think that would be a good idea. You don't want image decoding
  18. >  to slow down rendering or response to GUI events. The magic word here
  19. >  is: threads.
  20.  
  21. Where is the problem with decoding "slowing down" rendering ? The total
  22. time is the same and concurrent operation will give a wanted visual
  23. progress.
  24.  
  25. I also didn't say anything about "response to GUI events". I/O means
  26. network I/O. Sorry, if that was confusing.
  27.  
  28. >  The best way to implement a WWW browser would be to use threads with
  29. >  fixed priorities.
  30.  
  31. That's what AWeb does, although it runs the threads at the same fixed
  32. priority of 0.
  33.  
  34. >     3 rendering
  35. >     2 decoder (small images)
  36. >     1 decoder (large images)
  37.  
  38. And this is something you do not need. Why should rendering stop decoding ?
  39.  
  40. >  You can implement this on Amiga, but it doesn't work with dynamic
  41. >  priorities. If we would have threads on Amiga, there would be only
  42. >  one task to be scheduled.
  43.  
  44. We have threads, thank you. And no, most systems schedule threads.
  45.  
  46. >  And with this arrangement, small images would appear more quickly,
  47. >  not held back by one large image that takes ages to decode.
  48.  
  49. Not true. The appearance of images depends mainly on the order in which
  50. they are retrieved. If multiple connections are used then small images
  51. are automatically displayed faster.
  52.  
  53. Regards,
  54. -- 
  55.                                 Michael van Elst
  56.  
  57. Internet: mlelstv@serpens.rhein.de
  58.                                 "A potential Snark may lurk in every tree."
  59.